Traditionally, event processing has included processing any types of data, instructions, functions, etc. However, techniques for generating results of the event processing have generally been limited. For example, event processing has sometimes been utilized for function testing purposes.
Customarily, a fault within a function has been detected by utilizing a function test. Just by way of example, the function test utilizes a function to generate an output based on a known input. Further, the output is evaluated against known output. In addition, if the output matches the known output, then the function passes the function test. Additionally, if the output does not match the known output, then the function fails the function test. To this end, utilizing such traditional function testing has generally only been suitable when the path through a set of functions is constant. However, in the case where the path of the set of functions is not constant, utilization of such a function test has failed to indicate which particular function has failed. As an example, this case is especially true in environments where debugging facilities are unavailable, such as in production environments.
Furthermore, built-in-tests are traditionally utilized in embedded software environments in order to ensure the correct behavior of a component, a function, or a process. Still yet, in the built-in-tests standard practices, a test is deployed against a single function, otherwise, there may be an ambiguity as to what function malfunctions.
There is thus a need for addressing these and/or other issues associated with the prior art.